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ABSTRACT 


MATH MODELS are a series of algorithms, comprised of algebraic equations and Boolean Logic. At 
Kennedy Space Center, math models for the Space Shuttle Systems are performed utilizing the Honeywell 
66/80 digital computers, Modcomp 11/45 Minicomputers and special purpose hardware simulators (Micro- 
computers). The SGOS (Shuttle Ground Operations Simulator) operating system provides the language 
formats, subroutines, queueing schemes, execution modes and support software to write, maintain and 
execute the models. 

Ground systems presented here consist primarily of the Liquid Oxygen (LO 2 ) and Liquid Hydrogen 
(LH 2 ) Cryogenic Propellant Systems, as well as LO 2 External Tank (ET) Gaseous Oxygen Vent Hood/Arm 
and the Vehicle Assembly Building (VAB) High Bay Cells. 

The purpose of math modeling is to simulate the ground hardware systems and to provide an envi- 
ronment for testing in a benign mode. This capability allows the engineers to check out application 
software for loading and launching the vehicle, and to verify the Checkout, Control, & Monitor Sub- 
system (CCMS) within the Launch Processing System (LPS). It is also used to train operators and to 
predict system response and status in various configurations (normal operations, emergency and con- 
tingent operations), including untried configurations or those too dangerous to try under real con- 
ditions, i.e., failure modes. 


The Launch Processing System (LPS) at KSC consists of three primary subsystems: The Checkout, 
Control and Monitor Subsystem (CCMS), the Central Data Subsystem (CDS), and the Record and Playback 
Subsystem (RPS), (Figures 1 and 2). 

CDS consists of four large Honeywell 66/80 Digital Computers (Systems A, B, C and D). Systems 
A and B are designated as Set 1 and C and D as Set 2. Set 1 and Set 2 are identical. 

Within a Set the systems share mass storage and memory. The purpose of this is to facilitate 
switchover. Switchover is designed so the primary can switch to the secondary in case of a system 
failure (only during launch operations) utilizing the Real Time Data Management System (RTDMS). 

Each system has dual processors and each processor can handle 1.2 million instructions per sec- 
ond. Each system has a mos memory of 1.5 million (36 bit) words and within a Set share an additional 
1 million (36 bit) words of memory. Each set also shares 64 disk packs containing a total of over 12 
billion (36 bit) words of storage. 


Three operational modes exist for SGOS on CDS: (1) Real-time, (2) Remote Batch, and (3) Remote 

Terminal . 

Real-time mode operates with any of the three Launch Control Center Firing Rooms. FR-2 is nor- 
mally configured as the Ground Software Production Facility (GSPF), where model performances corre- 
spond to actual real world timing of events. It is here that GOAL Programs are de-bugged and veri- 
fied, and engineering evaluation and training take place. 

Remote Batch mode is initiated from a user's remote terminal. There is no interaction between 
the model and user once the "job" is submitted, and processing occurs at a much faster rate than 
real-time rate. All timing, however, is relative and kept consistent with real world activity. For 
example, in filling a tank with liquid in real time it may take 30 minutes, but in Batch Mode this 
time may be shortened to 1 minute, while preserving consistency throughout the entire model. Output 
from a Batch run can be printed or saved in mass storage. 

(♦Senior Field Engineer, MMC-KSC) 
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SHUTTLE GROUND OPERATIONS SIMULATOR (SGOS) 
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Remote Terminal Mode (non-real time) is used for creating source files of models, procedures, 
and data banks. Compilation of models and procedures is done via Terminal Mode. The model can also 
be executed in Terminal Mode, but the output is directed back to the user's terminal, where an inter- 
active session can occur. 

Engineering Displays, Full Trace, and selected Variable Column Trace and Plotting are available 
in both Terminal and Batch modes. 

Real-time also supports a logging capability similar in nature to the non-real time Full Trace, 
recording every change that occurs within the model, i.e., every calculation which produces a change 
in value or external stimuli which produces a change. 


SYSTEMS MODELED AND PURPOSE 


The types of systems involved in KSC Ground Math Models at LC39 are: 

1. Cryogenic Fluid Networks (LO^ and LH 2 ) 

2. Electrical Power Distribution Systems 

3. Mechanical Devices, GOX Vent Arm and Hood 

4. Pneumatic Actuators and Gaseous Supply Pressures and Purges 

Areas Modeled are: 

1. Vehicle Assembly Building (High Bays) 

2. Mobile Launch Platform (MLP) 

3. Pad Terminal Connection Room (PTCR) 

4. Launch Pad 39, Storage Areas and Burn Pond 

An End-to-End Nodal Analysis is necessary for modeling the cryogenic fluid networks, therefore, 
the LO 2 and LH? External Tank and Flow Path through the Orbiter are also modeled as part of the 
Ground System Models. 

The main purpose of the math models at KSC Is the checkout and verification of the Ground Opera- 
tions Aerospace Language (GOAL) programs 5 designed to automatically load and launch the Space Shut- 
tle. The programs must control and respond to the math model exactly as they would to the real hard- 
ware. 


At this point it would be helpful to discuss model fidelity. Model fidelity Is the degree of ac- 
curacy and completeness with which a model simulates the real world. There are, then, two distinct 
model forms, namely: imitators and predictors. 

An imitator is a model which is as complete as it must be, but is blind to any other conditions 
or anomalies. Coding in this fashion allows for computer processor efficiency, faster-running 
models, use of less file space, and easier maintainability. The main drawbacks are its limited scope 
and flexibility. An imitator is based mainly upon empirical data. 

A predictor is a model which can be written using (in addition to empirical data) real physical 
equations relating flows, pressures, temperatures, etc. Coding in this fashion is usually more diffi- 
cult, and in most cases requires more computer time. The obvious benefits are accuracy and flexibil- 
ity in testing new operational techniques, and accurate predictions of system response in abnormal 
and failure mode configurations. 

As it turns out, KSC models are a hybrid of these two forms, stressing predictive qualities in 
areas of fluid networks and associated calculated phenomena, and an imitative analysis in areas such 
as electrical power and pneumatics, where exact replication is unnecessary. 
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MODELING TECHNIQUES 


FLUID NETWORKS 


FLows and Pressures 


Accurate modeling of fluid networks has proven to be essential for cryogenic propellant loading. 
The fluid network shown in Figure 3 is for LH 2 and LO 2 . This is known as a nodal analysis, in which 
a node represents an exterior source or sink point, and interior points (points at which there is a 
fluid branch). The theory behind a nodal analysis is conservation of mass, or continuity, in which 
the sum of the flows into an interior node equals the sum of the flows out of that node. The bound- 
ary conditions must be known or calculated, and the internal admittance between nodes must also be 
known or calculated. A series of n simultaneous equations in n unknowns can be generated. The un- 
knowns we are solving for are the pressures at the nodes. The flows are the dependent variables, and 
once the pressures are solved for the flows are calculated. IN SGOS, the "CALL FLOW" statement pro- 
vides the format for easily setting up and solving any fluid network. Specifically, at boundaries 
where a source or sink exist, a pressure must be input at that node. The interior admittances, 
called G-numbers or Flow Constants, follow the inverse rules as electrical resistances where admit- 
tances in series sum as: 

1/G 2 t = 1 /G 2 x + 1/G 2 2 + 1/G 2 3 — + 1/G 2 n 
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TANK 
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and admittances in parallel sum as: 

Gt = Gi + G2 + G3 + — G n . 

However, the larger the value of the G-Number, the greater the flow. The flow constant was initially 
based on historical data and design information. It is simply a constant that is a function of the 
C v of the valve, the density of the fluid flowing through it and admittance of the plumbing between 
nodes. Originally the solution for flows and pressures was obtained by using an iterative calcula- 
tion similar in nature to the Runge-Kutta method. First a nodal analysis of the network is drawn, 
then the pressures at the ends or boundaries are calculated. The G-numbers are calculated along with 
the head pressures between the internal nodes. Once all the known quantities are computed, the flow 
rates are calculated using the flow equation: 

Q = G^| P 2 - Pi - HP 2 i 

where Q = Flow rate in gal/min 

G = Flow constant 

?2 = Upstream pressure 

Pi = Downstream pressure 

HP 21 = Head pressure between P 2 and 

The flows are iterated to increment the pressures to that the sum of the flows into each in- 
terior node equals the sum of the flows out. This method used enormous amounts of CPU time and the 

accuracy was very limited. 

SGOS developed the "Call Flow" routine in the Spring of 1981. This new method of computing 
flows and pressures used the same basic flow equation and nodal analysis as before as well as the 
Law of Conservation of Mass. 

Given boundary conditions of known pressures, and interior G's and head pressures, solve 
(iterate) for the pressures at the interior nodes first and then compute the flows. The method of 
computing these interior pressures uses a piecewise linear approximation for the vector square root 
function. Convergence is achieved in one (50 millisecond) model cycle as opposed to hundreds of 
cycles before which at best only approached convergence. 

The Flow Solver is processed in the SGOS executive, and is done with maximum efficiency, rather 
than having all the calculations performed in the model itself. The ease of formatting the fluid net- 
work and the reliable accuracy the flow solver achieves, has made true predictors out of the LO 2 and 
LH 2 models. 

During actual vehicle loadings. Flows, and Pressures were recorded. This data was used to re- 
compute more accurate flow constants, which then reflected all the dynamics in the system. Typical 

items that contribute to the flow constant between two nodes are: valves, orifices, pipes and plumb- 

ing, filters, and the fluid medium itself (viscosity/density). One additional consideration, vitally 
important, to be calculated and input to the fluid network calculation is the fluid head pressure. 

Head Pressure in the format for the "CALL FLOW" is input as a negative number when computing 
Flow from a lower elevation to a higher elevation. Knowledge of the system in terms of elevations 
of various nodes must be known, as well as the volume of liquid contained in various segments of pipe 
between nodes. This is necessary when filling or draining segments of pipe to allow realistic head 
pressure rise rates as the pipe fills up. When flowing "downhill" head pressure is added to the 
nodal pressure, and will increase the flow rate. When flowing "uphill" the head pressure is added 
to the nodal pressure and is used to reduce the flow rate. 


There are several limitations to the SGOS CALL FLOW statement which can be treated "outside" of 
the general matrix of simultaneous equations. These limitations are: fluid inertia, water hammer, 

non-continuous fluid networks (as when a segment of the network is drained), isolated interior net- 
works, check valves and one-way flow, and pumps between interior nodes. Detailed discussion of these 
items is outside the scope of this paper; however, these problems have been overcome in the cryogenic 
models. 
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Volumes 


Volumes of tanks, canisters, and pipes are needed in order to provide a realistic and accurate 
model. The volume of liquid in a tank at a source or sink node is computed by integrating, using a 
time constant, the net volume that exists in the tank - beginning with its initial volume and in- 
crementing by adding or subtracting the flow rate from that node. The SGOS "CALL INTGRL" statement 
is very useful for this purpose. "CALL INTGRL" provides the format where an integrand can be summed 
to at a fixed but selectable rate of from 10 times per second to once every 10 seconds. A one second 
update is normally used, but a number of special cases need faster or slower iteration rates. 

Volumes of pipes between nodes can be computed based on segment length and diameter, that fill 
and drain based on flow rates. Imaginary or pseudo wet/dry liquid sensors at each node triggers the 
calculations. 


Temperatures 

In most instances, temperature dynamics is done mostly for display purposes. A stagnant or 
empty segment of the fluid network will start off at an ambient temperature of 73° F. As cryogenic 
fluid enters a segment of the network, rapid boiling occurs and gaseous propellants will move down- 
stream, causing a pre-chi 1 1 down. At this point, we start calculating temperatures colder until ac- 
tual liquid (based on tests) would reach the location of a temperature probe. When the liquid volume 
reaches a probe, the temperature is assumed to be that of LO2 or LH2 at the Boiling Point. Very lit- 
tle change in temperature will occur thereafter. When the line is drained, the temperature will be- 
gin to rise. This rate may be rapid, unless the line is vacuum-jacketed. 

One notable exception where temperature fluctuations are pronounced, dynamic and critical is the 
feedline temperature in the LO2 system, which forewarns a geyser condition if redline criteria are 
exceeded. Due to head pressure in the feedline, this creates a very dynamic temperature profile dur- 
ing loading. 


ELECTRICAL SYSTEMS 

Power supplies are usually modeled in discrete terms. Power is either on or off, and sub-busses 
automatically receive power when the supply is turned on. Fuses are not modeled, but, in certain 
instances, circuit breakers are. Voltages and currents are assigned as constants based upon hardware 
data. These systems are handled rather simply, with very little dynamics involved. Every Function 
Designator will have a power bus assigned to it, and when the power is off that "FD" will read its 
powered-off value. Back-up batteries are also modeled, along with a limited amount of dynamics in- 
volved with threshold Zener Diode Systems. 

PNEUMATIC, GASEOUS SUPPLIES AND PURGE SYSTEMS 

Gaseous supplies are treated as inexhaustable reservoirs which supply GNo or Helium. Generally, 
these supplies are for purge systems and pneumatically actuated values. Modeling of these systems 
typically uses discrete logic, depending upon whether supply valves are open or closed. Dynamics are 
involved when a regulator is modeled using the line pressure as a feedback to the regulator to pro- 
vide more or less regulator opening. Another case involving dynamics is when a purge flows through 
a heater where heater temperature is a function of a cool purge flowing through it. All pneumatic 
values are modeled to require a specified minimum supply pressure to operate. Helium bubbling in the 
LO2 feedline is modeled to provide a realistic temperature gradient profile. This will influence the 
head pressure in the feedline. 

It is noteworthy to mention that for the LHo system, helium is always used when cryogenic hydro- 
gen may be present, due to the fact that the boiling point of helium is lower than that of LHo. If 
GNo were used in contact with LH2, the nitrogen would form GN2 ice. In the LO2 system both GN2 and 
Helium can be used since GN2 stays gaseous at liquid oxygen temperatures. For economy, GN2 is gener- 
ally used with LC^. 


MECHANICAL SYSTEMS 

The ET GO2 Vent system consists of a heated purge and a hinged cantilevered truss assembly sup- 
porting a conical shaped plenum chamber (which also is hinged). It is moved to a docking position 
with the ET nose cone to provide an environment for warming the nose cone while venting GOp, which 
prevents ice build-up on the ET. The simultaneous motions of the arm and hood, primary ana secondary 
drives, presented an interesting challenge in designing the math model. 
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MODEL DEVELOPMENT 


DATA COLLECTION: FEEDBACK TO MODEL THROUGH STS-1 

Sources for model data include: 

1. The original schematics and specifications 

2. Discussions with engineers about operating parameters 

3. Consulting with vendors on specific hardware items, and actual test data during system opera- 
tion. After a hardware test (such as a tank loading) or an actual launch, a quantitative analysis is 
done on the data collected, and is compared to model output. From this analysis we can provide accu- 
rate empirical data and write more comprehensive equations for further model development. When new 
operating techniques are employed during a simulated loading, model predictions can also be verified 
by test data later. 


ADVANCED DEVELOPMENT: STS-2 THROUGH STS-5 

Advanced development has included continual feedback from hardware testing and launch data. 
Hardware modifications have also been fairly regular throughout each flight, and model dynamics have 
been heavily impacted. A "New Standards and Guidelines for Math Models" (KSC-80K00009) has insti- 
tuted numerous convention and fidelity conformities. This was necessary in order to coordinate and 
make common, models written by all KSC and Vandenberg Air Force Base contractors. This has also 
specified the identification of all Ground and Vehicle interfaces, and all system interfaces to be 
recorded in the "Math Model Interface Definition Document" (MMIDD). 


FUTURE DEVELOPMENT: STS-6 AND BEYOND 

Model enhancements will dominate this effort, along with sustaining engineering for hardware mod- 
ification. The most significant hardware change was the development of the Martin Marietta Light 
Weight External Tank. STS-6 was launched April 4, 1983, with the first lightweight tank. At the 
time of this writing, STS-7 is scheduled for launch in mid-June and will have successfully completed 
its mission a week before this conference. 

Future plans include the installation of a Centaur stage in the Orbiter cargo bay, which will be 
fueled with LO 2 and LHo simultaneously with the External Tank. This will present a new challenge for 
modeling as the LO 2 and LH 2 fluid networks will be modified to accommodate this space vehicle. At 
present, the first Centaur launch, STS-38, is scheduled for May, 1986. 

Study plans are under way at Martin Marietta for Shuttle derived vehicles. Advanced Space Trans- 
portation System (ASTS), which include an aft cargo carrier (ACC) or shroud on the External Tank, 
with a cargo carrying volume greater than that of the Orbiter Cargo Bay. 

Launch Complex 39B should be in operation by January 1, 1986, and the first launch will be STS- 
36, in February, 1986. Pad-A & B at KSC will be very similar, requiring only slight model changes. 
Mobile Launch Platforms (MLP) 1 and 2 are in use now with some hardware differences, and MLP-3 is 
being processed at this time. 

Vandenberg models were patterned after KSC models, with some hardware differences inherent to 
VAFB. Their first launch (IV) is scheduled for October, 1985. Plans are for KSC to operate with 
0V99, 0V102 and 0V104 and VAFB to operate with 0V103. 

The next major event for math models at KSC will be in June, 1983, with the implementation of 
the expanded model capability project also known as BIG SIM. Currently, the largest master model 
which can be built is approximately 227K words. It may be possible that BIG SIM will expand that 
size 2 or 3 times. This new capability will allow for an integrated test of a launch countdown model 
with all consoles supporting. Also this will greatly increase GSPF support time by allowing more 
users to operate the model simultaneously (restricted only by the processor's capability). This will 
greatly reduce the GSPF's down time, because at present each of several smaller master models must be 
loaded, which can take several hours, during which time there is no model support. Once a large 700K 
master model is loaded and running, it can support continuously, with changes necessary only to up- 
date the master model. Changes will not be necessary for scheduling purposes. 
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With the large master models it will be necessary to streamline all existing models, to write 
more efficient code, and to understand how model segments are ranked, queued and executed. Caution 
should be exercised in attempting to make a model segment run faster, while at the same time, not 
adding more of a burden to the model executive processing. 


CONCLUSION 

Math modeling presents a unique opportunity to intimately blend engineering/hardware knowledge 
with computer technology. Since a model must perform identically as the hardware, a very broad knowl- 
edge is gained by the modeler in both the hardware and the software. Within the environment of opera- 
tions and maintenance, this author has found model research and development to be challenging and 
satisfying. 


In closing, I would like to quote from Kenneth P. Timmons, Michoud Division Vice President and 
General Manager, at an address to 300 members of the Louisiana Tech University Engineers Association 
in Ruston, Louisiana, March, 1983: 

3"In your generation, which saw polio conquered and man landing on the Moon, I believe the 
greatest advance is the ability to model events, states and phenomena and to process these models in 
small fractions of seconds in large capacity computers. 

Engineers have contributed to these achievements and will continue to make us part of the techno- 
logical triumphs - such as the Space Shuttle - today." 
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